home Today's News Magazine Archives Vendor Guide 2001 Search isdmag.com

Editorial
Today's News
News Archives
On-line Articles
Current Issue
Magazine Archives
Subscribe to ISD


Directories:
Vendor Guide 2001
Advertiser Index
Event Calendar


Resources:
Resources and Seminars
Special Sections


Information:
2001 Media Kit
About isdmag.com
Writers Wanted!
Search isdmag.com
Contact Us





Say It Aint So, Joe

By Peggy Aycinena
Integrated System Design
Posted 03/12/01, 02:02:23 PM EDT

It's hard to get through to Joe Pumo, director of Motorola's System-on-Chip Design Technology Group. He's behind a human firewall that can neither be penetrated nor scaled by ordinary mortals. And why does 'Moto' have Pumo under wraps? For those lucky enough to finally talk to him, the answer's immediately clear — he's smart, articulate, and a 22-year veteran of the organization. Most importantly, in this emerging era of system-on-a-chip design, he's actually done the deed — he's headed up a real team that's designed and manufactured real SOCs. Lot's of people can talk the SOC talk, but few can say they've walked the SOC walk. When it comes to complex chips — system chips — Joe knows his stuff.

What is a system on a chip for Pumo? He says, "An SOC has several aspects. It's a hardware and software solution with several ingredients." First, it has to provide hardware/software components for the customer. Second, it has to fit a customer's application. Additionally, it has to generate product and it has to be aligned with a methodology for a top-down design flow. Pumo's definition for an SOC is a subtle one mixing, as it does, both end-product specification and design methodology. For on-chip components, he says SOCs usually have a general-purpose microprocessor, an API device driver, and typically include some analog and mixed-signal capability along with a DSP engine.

Motorola and Joe Pumo have been involved in a range of products over the years — automotive, wireless, imaging, networking — which have, in turn, addressed a variety of design specs: low power, high performance, high temperature functionality, or a mix of each. Per Pumo, the toughest part in these designs has become timing convergence, an effort that can take "weeks and weeks" in comparison to other phases of development. He says the combination of timing closure and design verification have become the biggest hurdles in product development.

Additionally, Pumo says system chips are going to require system-level languages. "There's kind of a gap right now. We have to prove the [system-level] languages really work." He says that C/C++ are currently serving in that capacity — "We're behind SystemC" — but efforts are needed to take the C languages down to the RTL level, and to get "more and more" verification capability there.

Included in the wealth of experience that Motorola has accumulated over the years — Pumo says that the first Motorola SOC came off the line in the late 90's — the company has examined many third-party design tools. He says his team regularly uses commercially available DFT and verification tools, among others. They don't want to "duplicate" EDA offerings with in-house tools, but "we do need to complement" those offerings when additional capabilities are needed for a project which are not met adequately by vendor-supplied tools. He adds, "EDA can't just work with universities to come up with a perfect solution." EDA must work closely with their customers to understand real-world problems if they hope to come up with real-world tools that are commercially viable.

Pumo understands that there are some current EDA offerings that promise to handle the entire design flow. He points out that it's often important to be able to go "in and out of the flow" in order to insert a different vendor's point tool — or an in-house tool — to meet a particular design need. If an EDA tool suite disallows this type of flexibility, it's probably not as useful as it needs to be, he says.

Motorola ends up running a lot of EDA tools through their paces in order to determine if they will be of use on a project. The company has, therefore, effectively done benchmarking on most tools on the market today. Pumo thinks it's an intriguing idea to publish that benchmark data, perhaps as a service to the industry. (One has to wonder, however, how the human firewall might feel about that.) Pumo says that Motorola is involved with the ASIC Council, and that he agrees with the company's commitment to the concept of co-opetition — cooperating with the competition so that everyone benefits and can move forward on problems best solved as an industry.

Pumo's originally from Pittsburgh and has been in the semiconductor industry for 25 years. He acknowledges that he's got little time outside of work, but when there are extra hours, he enjoys his family and "the simple things." He likes to play racquetball and watch baseball — in particular, when his son played for the Texas Longhorns (that's University of Texas, Austin). For anybody who's had the pleasure of watching their own kid play ball, you knows there is no greater form of the game. Not surprisingly, Joe coached Little League for years, up until his kids hit high school, and it sounds like he regrets having had to leave it behind.

These days he's still coaching, but it's an SOC team rather than Little League. He says, in that capacity, Babe Ruth has words of wisdom for design teams. Pumo paraphrases Ruth: "You can have the best players in the world, but if they don't learn to play as a team, the players individually aren't worth a dime." Similarly, Pumo says, you can have the best engineers in the world, but if they can't learn to think as a team on a semiconductor project, next to nothing can be accomplished.

   Print Print this story     e-mail Send as e-mail   Back Home

Sponsor Links

All material on this site Copyright © 2001 CMP Media Inc. All rights reserved.